U.S. App. No. 10/082,677 
Response to 6/1/07 Office action 

Amendments to the Specification 

Please add the following heading and sentence as the first sentence of the application following 
the title: 

RELATED APPLICATIONS 

This application is a 371 of U.S. Provisional Application No. 60/271,156 filed on 
February 23,2001. 

Please replace page 6, lines 7-8 with the following rewritten paragraph: 

FIG. 8 is a diagram illustrating the processing performed by a mainfi-ame adapter 
component. compon e nt 

Please replace page 7, lines 14-22 with the following rewritten paragraph: 

FIG. 1 illustrates the architecture of an electronic payment system 30. The system 30 
provides networked merchants (e.g., Intemet merchants or retailers) with the ability to receive 
paperless, electronic check payments check, paym e nts firom consumers coupled to the network. 
Electronic checks cost substantially less to process than credit charges and r -and-speed the 
movement of money into the merchant's account relative to paper-based checks. The system 30 
includes a consumer or purchaser terminal 32 where the consumer places an order and chooses 
an electronic check as the form of payment. The order and payment information is transferred to 
a computer 34, preferably a server, controlled by the Intemet merchant. 

Please replace page 9, lines 7-19 with the following rewritten paragraph: 

If the consimier decides to pay for the product or the service with an electronic check, the 
system 30 illustrated in FIG. 1 may be utilized. FIGS. 1 A and IB illustrate exemplary payment 
(data capture) pages as they might appear in the browser (e.g., a web browser such as Microsoft 
Intemet Explorer or Netscape Navigator) of the consumer terminal 32. In one embodiment, the 
data capture pages acquire information via the web in a secure manner using standard web 
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interface technologies. FIG. 1 A illustrates a page 40 having a dialog box 4442. The dialog box 
44 42-includes entry areas for a consumer's name, address (street, city, state, zip code and 
country), phone number, date of birth, driver's license, and driver's license state. In one 
embodiment, in an effort to make the process simple and non-redundant, information supplied by 
the consumer to the merchant at the "checkout" page is automatically entered in the 
representative entry areas of the dialog box 4442. The consumer may correct information if it is 
not displayed correctly. 

Please replace page 13, lines 3-22 with the following rewritten paragraph: 

As shown in FIG. 3, the authorization computer 36 may be designed with various security 
and backup features, additional hardware to support applications, and hardware to format and 
route data to the additional hardware. In the example shown, the authorization computer 36 
includes a first firewall 140, a primary server 142, a failover server 144, a second firewall 146, 
and a converter and router 148 that performs integrated data capture and convert ("IDCC") 
operations and that executes a rules and formatter application 149. The converter and router 148 
is connected to a tracking server 150 and an application server 152. A pass-through Java servlet 
153 running on the primary server 142 sends the customer's transactional debit data request to a 
Java server 147 running on the converter and router 148. The Java server 147 places the input 
request (considered a ''transaction" "transaction ) into a queue for the rules and formatter 
application 149 running on the converter and router 148. The rules and formatter application 149 
pulls the transactions from its queue one-at-a-time to perform formatting and data conversion 
operations on each transaction. The rules and formatter application 149 puts the transaction into 
a queue for the tracking server 1 50 for creating a log of transactions. A tracking application 1 54 
running on the tracking server 150 creates the log of the transactions, making them available to a 
transaction inquiry application used for diagnosing transaction problems. Each formatted and 
converted transaction is routed to the electronic check module 70 running on the application 
server 152. 

Please replace page 20, lines 15-21 with the following rewritten paragraph: 
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Preferably, the message structure in the mainframe-to-mainframe channel includes a 
number of tagged or tokenized message components. In this one preferred embodiment, each 
message component in the request message is made up of the following parts: a 3 -byte data 
length field, a 4-byte data code field, and the subject data. A special CICS transaction identifier 
may be assigned to the electronic check transactions transaction to differentiate them fi-om other 
electronic requests^ such as identification verification requests (which are discussed below). 

Please replace page 28, lines 26-31 and page 29, hnes 1-6 with the following rewritten 
paragraph: 

The identity verification module 800 may utilize the first of the two filters to perform 
firaud indicator searches. Fraud indicator searches may include validation procedures on phone 
number information (the area code and prefix are compared against a valid list of area code 
prefix combinations; the standard and extended lists of phone types of the associated area 
code/prefix are returned when the area code/prefix is not identified as a plain old telephone 
service ("POTS") number), phone number to zip code information (the area code and prefix of 
the home phone number are compared to the zip code associated with the billing address), DOB 
to SSN date of issuance ("DOl") information (the input DOB is compared to the DOI returned 
fi-om a successfiil match to the SSN), address to warm address information (the billing address 
and ship to address are compared against a table of addresses identified as non-residential, non- 
locations, i.e., mailboxes, prisons, vacant lots, etc.), and the like. 

Please replace page 29, lines 7-31 and page 30, lines 1-18 with the following rewritten 
paragraph: 

The identification verification module 800 may utilize the second of the two filters to 
perform consumer identity validation searches. Consumer identity validation searches may 
include validation procedures on DL within state (the format of the input DL is compared to the 
valid format for the given state, the input DL may then be compared to Department of Motor 
Vehicles ("DMV") files for a hard match if the service is available in the state), SSN/individual 
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taxpayer identification number ("ITIN") (the input SSN or ITIN is compared to the Social 
Security Administration valid and/or issued social security groups as well as compared to 
SSN/ITIN identified as deceased or bogus), DL DOB to SSN DOI (the DOB retumed fi-om a 
successfiil match to the DL on DMV files is compared to the DOI retumed fi-om a successfiil 
match to the SSN if the input DOB is different than fe at-the DL DOB), DOB to DL DOB (the 
input DOB is compared to the DOB retumed fi-om a successfiil match to the DL on DMV files). 
Consumer identity validation searches may also include validation procedures on the consumer's 
name. An input name may be compared against a consumer search table of standardized names 
returning the standardized name. The standardized name will be used in the subsequent 
matching of name to DL, name to consumer address, name to SSN, name to phone number and 
name to MICR. A candidate key, based on a fiizzy match algorithm, may also be used in the 
subsequent matching of name to DL, name to consumer address, name to SSN, name to phone 
number and name to MICR.. Validation procedures may also be performed on a consumer's 
address to zip code (the consumer address state, city, and zip code are compared within 
identified geographical identifiers and are standardized; invalid zip codes are corrected in cases 
where the address, city and state combination is valid as well as a valid postal city name supplied 
when the zip code and address match within the state); name and address (associations between 
the name and the billing address are searched using the name and address candidate key); name 
and DL (associations between the standardized name and the input DL are matched against a 
cross reference name to DL to identify if prior associations can be found returning the number of 
sources that were found); name and SSN (the candidate key from the name search and the input 
SSN or ITIN is matched against a cross-reference candidate key to SSN to identify if prior 
associations can be found returning the number of sources that were found); name and phone 
number (the candidate key from the name search and the input home or work phone number is 
matched against a cross-reference candidate key to phone numbers to identify if prior 
associations can be found returning the number of sources that were found); name and MICR 
(the candidate key from the name search and the input MICR is matched against a cross- 
reference candidate key to MICR (bank code plus demand deposit account ("DDA") account 
number) to identify if prior associations can be found returning the number of sources that were 
found); name and address and DOB (the name, address and DOB are compared against each 
other for a match); MICR and phone number (the MICR and phone number are compared 
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against each other for a match); MICR and address (the MICR and address are compared against 
each other for a match); name and address and phone number (the name, address and phone 
number are compared against each other for a match), etc. 
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Please replace page 36, lines 22-26 with the following rewritten paragraph: 

The converter 1 350 may also perform parsing. Parsing may be utilized to break a single 
name and/or address addr e ss e s data field into a number of data fields representative of specific 
components of the name and/or address (e.g., name parsed into last name, first name, and middle 
name or initial). Parsing may also correct some address information. 

Please replace page 39, lines 3-18 with the following rewritten paragraph: 

The matching process is illustrated in FIG. 18. The matching module 1224 of the debit 
data search engine 1220 performs matching. In one embodiment, the matching module 1224 
performs name/address searches, name/previous address searches, name/DL searches, 
name/phone number searches, name/MICR searches, MICR/phone number searches, and 
MICR/address searches. The matching process is flexible and may allow for matching based on 
other data attribute combinations. The entity requesting validation of debit data has the ability to 
specify which searches it would like performed. The parameters can also specify the order of the 
searches to be performed. The parameters are submitted to the calling application 1210 along 
with the data stream. In an alternative embodiment, the parameters can be setup for the entity 
and utilized whenever the entity submits debit data to be validated. The ability to adjust the 
parameters allows the entity to specify what searches and what order of searches are optimal for 
a given transaction. For example, some transactions may receive the SSN only 10% of the time. 
It is not optimal to perform a SSN search in such a situation. However, if a type of transaction 
always receives the SSN, a SSN search might be the first search attempted. 

Please replace page 40, Hnes 5-15 with the following rewritten paragraph: 

The debit data search engine can use two types of matching: fiizzy matching and hardkey 
matching. Fuzzy matching compensates for variations in names (e.g.. Bob, Robert, Rob), 
variations in spellings (e.g., Chris, Kris), and miss-spellings (Maple, Mapel). Fuzzy matching 
allows for the adjustment of matching parameters to make the matching process more or less 
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Stringent. As discussed, the matching parameters may be provided by the entity requesting 
validation of debit data. Hardkey matching searches for the exact characters with no variation. 
When using a hardkey matching search, a last name and phone nxmiber m atch does not allow for 
any variation in the last name or the phone number. These same matching strategies can be 
utilized in the matching component of the linking process, although it is preferred to utilize the 
hardkey matching when performing the linking process. 
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